^-8155  853L  ENHflNCEHENTS  MADE  TO  THE  TRIDENT  ASSIGNMENT  PROGRAMCU) 
LOGICON  INC  SAN  PEDRO  CA  STRATEGIC  AND  INFORMATION 
SVSTEMS  DIV  J  k'  REEDER  24  JAN  91  DNA-TR-91-lb 
UNCLASSIFIED  DNA001-87-C-0177  F/G  16/2 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANWRDS-1963-A 


DNA-TR-91-16 


AD-B155  853 


t* 


Enhancements  made  to  the  Trident  Assignment  Program 


Logicon,  Incorporated 

Strategic  and  information  Systems  Division 

P.  O.  Box  471 

San  Pedro,  CA  90733^71 

24  January  1991 
Technical  Report 


CONTRACT  No.  DNA  001-87-C-0177 


Further  dissemination  only  as  directed  by  the 
Defense  Nuclear  Agency,  6801  Telegraph 
Road,  Alexandria  VA  22310-3398,  4 
Febmary  1991  or  higher  DoD  Authority. 


This  work  was  sponsonad  by  the  Defense  Nuclear  Agency  under  RDT&E  RMC  Codes 
84697  C  RO  RB  00005  NASF  2430  A  and  B4697  C  RO  RB  156  NASF  2430  A  25904D. 


Prepared  for: 

Defense  Nuclear  Agency 
6801  Telegraph  Road 
Alexandria,  VA  22310-3398 


9l  6  21  09  5 


91-03158 


REPORT  DOCUMENTATION  PAGE 

Form  Approvod 

0MB  No.  0704-01 88 

Pubfoc  r«9onino  bufdtn  tor  ttwa  coHoction  et  irtformttion  »t  otiimototf  lo  tvortgo  1  t>our  por  roipooM.  toclutfmg  mo  ttm#  tor  ro^ttwrwg  mnruaior>o.  loorchirtQ  o««ftir«o  dato  oourcot. 
pomorioo  arxl  moKWomioQ  mo  doto  noodod.  or>d  complotirtQ  and  fowowtr^g  tho  cottoaion  o<  mtormation.  8or>d  oommorwo  ropardroQ  thtt  dufdon  ooianaia  or  any  emor  aopoo  ot  m« 
coHociion  ot  intormatNm.  irKiudtng  autpoMiona  for  roducing  thta  burdon.  to  Waahiopion  Hoadquanora  Sorvtcoo.  Dtrocforaia  for  Information  Oporatiorta  artd  Roftorti.  1215  Jotforaon 
Oavia  Htfhway.  Suita  1204,  Arlmpton.  VA  22202«4302.  and  to  tha  Offico  ot  Manapamont  and  Bodpot.  Paporurorii  Roduction  Profoct  f0704»0l  M).  Waahmfton.  DC  20503 

1.  AGENCY  USE  ONLY  riaava  Wan*;  2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

Technical  -  870808  -  910124 

4.  TITLE  AND  SUBTITLE 

Enhancements  made  to  the  Trident  Assignment  Program 

5.  FUNDING  NUMBERS 

C  -  DNA  001-87-C-0177 

PE  -  62715H 

PR  -  RO 

TA  -  RB,  RZ 

WU  -  DH039910 

6.  AUTHOR(S) 

Jerold  K.  Reeder 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESSIES) 

Logicon  Incorporated 

Strategic  and  Information  Systems  Division 

P.O.  BOX  471 

San  Pedro.  CA  90733-0471 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

9^|PONSOF|^GijMgNIT^RING^AGENCY  NAME(S)  AND  ADDRESSIES) 

6801  Telegraph  Road 

Alexandria,  VA  22310-3398 

NASF/Griffin 

10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 

DNA-TR-91-16 

11.  SUPPLEMENTARY  NOTES 

This  work  was  sponsored  by  the  Defense  Nuclear  Agency  under  RDT&E  RMC  codes  B3860 
874697  RO  RZ  00003,  B4697C  RO  RB  00005  NASF  2430A,  B4697C  RO  RB  NASF  2430A  25904D. 

128.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Further  dissemination  only  as  directed  by  the  Defense 
Nuclear  Agency,  6801  Telegraph  Road,  Alexandria,  VA 
22310-3398,  4  February  1991,  or  higher  DoD  authority. 

12b.  DISTRIBUTION  CODE 

13.  ABSTRACT  (Maximum  200  words) 

The  Trident  Assignment  Program  (TAP)  is  part  of  a  Trident  missile  planning  system 
developed  by  the  British  Royal  Navy.  Changes  were  made  to  the  TAP  program 
including  the  incorporation  of  a  launch  timing  and  fratricide  deconfliction 
capability.  The  capability  will  minimize  the  timespan  of  launches,  minimize  the 
timespan  of  impacts,  or  minimize  occurances  of  fratricide  within  a  fixed-rate 
schedule.  Other  minor  enhancements  were  also  made  to  the  missile  assignment 
portion  of  TAP. 

14.  SUBJECT  TERMS 

Mission  Planning 

Missile  Application 

Timing  and  Deconfliction 

15.  NUMBER  OF  pages 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION 
OF  REPORT 

UNCLASSIFIED 

18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

UNCLASSIFIED 

19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 

UNCLASSIFIED 

20.  LIMITATION  OF 
ABSTRACT 

SAR 

NSN  7540-01  -280-5500  -i  Standard  Form  298  (Rav.  2-89) 

PTMcribad  by  ANSI  St«.  239-1 8 


298-102 


SUMMARY 


This  report  describes  the  updates  and  enhancements  incorporated  into  the  Trident  Assignment 
Program  (TAP).  TAP  is  computer  software  used  by  the  British  Ministry  of  Defence  for  creating 
Trident  II  strategic  plans.  The  primary  enhancement  performed  under  this  contract  was  a 
capability  to  schedule  missile  launches. 

Capabilities  of  the  scheduling  function  include  minimizing  the  time  needed  to  launch  all  the 
missiles  from  each  boat,  minimizing  the  time  needed  to  detonate  all  reentry  bodies  (RBs),  and 
launching  missiles  at  a  fixed  rate.  Fratricide — that  is,  one  nuclear  detonation  destroying  another 
weapon  before  it  can  detonate — is  a  major  consideration  when  scheduling.  TAP  minimizes 
fratricide  by  scheduling  to  avoid  it  where  possible. 

Enhancements  were  also  performed  to  TAP’s  missile  assignment  processing.  These  included 
updating  the  program  with  the  latest  Trident  II  data,  improving  user  controls  over  the  number  of 
hits  a  target  receives,  and  processing  relocatable  targets. 
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SECTION  1 
INTRODUCTION 


The  Trident  Assignment  Program  (TAP)  was  developed  for  the  British  Royal  Navy  under  a  prior 
contract,  DNA001-84-C-0297.  In  that  effort,  the  Joint  Strategic  Target  Planning  Staffs  (JSTPS) 
missile  application  program,  M202,  was  customized  to  meet  the  needs  of  the  Royal  Navy. 

TAP  is  a  full-featured  missile  planning  program  for  the  Trident  II  system.  Given  aimpoints,  a 
Trident  arsenal,  and  direction  from  the  planner,  it  can  assign  specific  missiles  and  warheads  to 
specific  aimpoints  and  schedule  the  launches  of  those  missiles.  When  assigning  missiles  to 
aimpoints,  TAP  attempts  to  cover  highly  valued  and  critically  important  aimpoints,  forgoing 
lesser  DGZs  (desired  ground  zeros)  if  necessary.  TAP  selects  launch  times  that  minimize 
fratricide,  yet  satisfy  other  planner  objectives  prescribing  bounds  on  the  schedule.  Figure  1  shows 
the  major  components  of  TAP  and  how  they  work  together. 

Work  under  the  current  contract  primarily  involved  the  development  of  the  scheduling  capability. 
A  portion  of  the  processing  was  derived  from  the  Advanced  Missile  Model  (AMM),  a  program 
used  by  the  Air  Force  Center  for  Studies  and  Analyses.  The  fratricide  calculations  used  with  TAP 
were  from  the  Nuclear  Weapons  Environment  Model  (NWEM),  a  DNA  program.  The  other 


Trident  Assignment  Program 


Figure  1.  Major  components  of  TAP. 
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portions  of  the  scheduling  code  were  developed  in  concert  with  the  Director  General  Strategic 
Weapons  Systems  (DGSWS)  organization  of  the  British  Ministry  of  Defence. 

Other  upgrades  were  made  to  TAP  under  this  contract,  as  well.  Many  changes  were  made  to  the 
assignment  portion  of  the  program  to  tailor  it  more  directly  to  British  needs.  These  will  be 
described  in  later  portions  of  this  document. 

The  schedule  under  which  this  effort  was  performed  is  shown  in  Figure  2.  There  were  two 
primary  deliveries:  TAP.3  and  TAP.4.  In  the  following  sections  of  this  report,  the  tasks 
performed  for  each  of  these,  as  well  as  the  other  support  work  provided  to  DNA  and  DGSWS,  is 
described.  Work  on  this  contract  was  accomplished  on  schedule  and  within  budget. 


2 


SECTION  2 

TAP.3  ENHANCEMENTS 


The  enhancements  provided  for  the  third  major  version  of  TAP  included: 

•  rehosting  the  program  from  the  IBM  mainframe  and  Perkin-Elmer  computers  to  Digital 
Equipment  VAX  machines 

•  replacing  Trident  C4  code  of  the  earlier  versions  with  Trident  D5  processing 

•  including  EXjSWS’s  Dummy  Simplified  Trident  Rapid  Achievability  Predictor  (STRAP) 
accessibility  model  instead  of  STRAP  for  determining  achievability 

•  introducing  special  processing  techniques  for  relocatable  targets 

•  multiple  hitting  of  specified  DGZs  in  preference  to  hitting  other  DGZs  singly 

•  scheduling  sortie  launches  that  minimize  the  span  of  time  required  to  launch  the  missiles, 
without  exceeding  fratricide  limits 

Each  of  these  enhancements  is  described  in  the  following  sections. 

REHOSTING  TAP  TO  VAX  COMPUTERS. 

Initially,  TAP  was  developed  on  an  IBM  mainframe  compatible  with  the  TRICOMS  computer 
system  at  the  Strategic  Air  Command.  The  first  version  of  TAP  was  converted  to  run  on  the 
DGSWS  Perkin-Elmer  system.  The  second  version  of  the  program,  developed  under  a  prior 
contract,  was  also  hosted  on  the  Perkin-Elmer  computer. 

Logicon  ported  the  code  to  a  third  platform,  the  VAX,  as  the  first  task  in  preparing  TAP  version 
3.  This  conversion  involved  modifying  file  names,  preparing  control  language  to  execute  the 
program,  and  changing  source  code  that  was  incompatible  with  the  VAX. 

After  these  tasks  were  performed,  a  wide  range  of  tests  was  run  to  compare  the  results  achieved 
on  the  IBM  with  those  on  the  VAX.  Once  TAP  was  baselined  on  the  VAX,  the  other 
development  tasks  commenced. 
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REPLACING  TRIDENT  I  WITH  TRIDENT  11. 

The  first  versions  of  TAP  were  delivered  with  the  capability  of  assigning  Trident  C4  missiles. 
This  was  because  programs  to  model  D5  missiles  had  not  yet  been  developed  by  the  Naval 
Surface  Warfare  Center.  The  initial  C4  capability  allowed  the  British  planners  to  begin 
examining  the  processes  of  missile  planning  while  awaiting  the  final  products. 

With  TAP.3,  the  Trident  II  models  became  available,  so  the  program  was  updated.  The  primary 
impact  on  the  program  was  a  change  in  nomenclature  on  the  inputs  and  reports.  Minor  changes 
were  required  in  the  processing  to  invoke  the  Trident  11  achievability  model. 

UTILIZING  DUMMY  STRAP. 

For  security  reasons,  DGSWS  was  unable  to  release  STRAP  for  D5  to  Logicon.  To  allow 
software  development  and  testing  to  continue,  DGSWS  therefore  prepared  a  “Dummy  STRAP” 
that  would  simulate  missile  trajectories  in  an  unclassified  fashion.  This  module  was  incorporated 
into  TAP  for  use  during  development  and  acceptance  testing. 

One  portion  of  STRAP  not  replicated  in  Dummy  STRAP  was  the  “domain”  computation.  A 
domain  is  an  elliptical  region  centered  on  the  first  DGZ  selected  for  a  sequence,  as  shown  in 
Figure  3.  Its  area  includes  all  other  DGZs  that  might  possibly  be  included  with  the  first  DGZ  in  a 
complete  sequence.  Its  major  and  minor  axes  provide  a  quantitative  estimate  of  the  relative  fuel 
used  for  performing  downrange  maneuvers  vs.  crossrange  ones.  The  size  and  shape  of  the  ellipse 
are  determined  by  azimuth,  range,  and  weapon  configuration.  These  domain  factors  arc  used 
extensively  in  selecting  DGZs  for  use  in  a  sequence,  and  for  ordering  those  DGZs.  Because  this 
domain  data  was  not  provided,  Logicon  functionalized  it  by  executing  TRAP.2,  JSTPS’s  Trident 
II  Rapid  Accessibility  Program,  thousands  of  times,  for  a  wide  range  of  azimuths  and  flight 
distances.  The  resulting  data  was  fit  to  curves  and  incorporated  into  TAP.3.  Because  the  domain 
data  is  used  as  a  guide  rather  than  an  assignment  acceptance  criterion,  minor  future  changes  to  the 
missile  performance  modeling  do  not  necessitate  recomputing  the  coefficients  of  the 
functionalization.  However,  if  STRAP  has  major  performance  updates,  the  coefficients  should  be 
derived  with  the  new  models. 
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RELOCATABLE  TARGET  PROCESSING. 

The  relocatable  target  (RT)  processing  incorporated  into  TAP.3  addresses  the  problem  of  RTs 
operating  in  a  well-defined  area  around  a  main  operating  base  (MOB).  The  TAP  program  will 
only  assign  missiles  to  RTs  if  the  RTs  can  be  kept  at  risk  while  they  roam  arbitrarily  about  their 
operating  area.  For  TAP’s  purposes,  operating  areas  are  defined  as  circular  and  contain  the  MOB 
as  well  as  the  entire  area  within  which  the  RTs  can  relocate.  The  user  can  specify  at  runtime  the 
minimum  required  probability  of  keeping  the  RTs  at  risk.  Lower  allowed  probabilities  provide 
more  targeting  flexibility. 

The  process  TAP  uses  to  determine  if  a  particular  missile  is  suitable  for  assigning  to  RTs  is  to 
compare  the  operating  area  with  a  computed  “set  potential  circle.”  Set  potential  circles  are 
regions  wherein  RTs  may  move  and  be  kept  at  risk  with  a  given  probability:  smaller  probabilities 
yield  larger  circles.  The  circles  are  derived  from  curve-fit  functionalizations,  and  vary  with 
weapon  configuration,  azimuth,  and  range  from  missile  to  targets.  Figure  4  shows  the  geometry 
of  this  scenario.  In  general,  weapons  with  fewer  RBs  and  shorter  ranges  to  the  target  area  will 
have  larger  set  potential  circles.  A  missile  can  be  assigned  to  only  those  RTs  whose  operating 
area  lies  within  the  set  potential  circle  for  the  particular  combination.  RTs  not  eligible  for  a 
particular  missile  will  be  left  for  other  missiles  that  may  be  able  to  cover  them  due  to  fewer  RBs 
or  shorter  range. 


5 


Sat  potantial  circia 


Mam  oparating  baaa 
RT  oparating  area 

Relocatable  target 
Fixed  target 


Figure  4.  Relocatable  target  scenario. 


Like  the  domain  functionalizations  above,  the  set  potential  circle  coefficients  may  need  to  be 
redenved  if  the  achievability  model  changes  significantly. 


MANDATORY  MULTIPLE  HITS. 

With  M202,  and  hence  the  earlier  versions  of  TAP,  a  program  objective  was  to  cover  as  many 
targets  as  possible.  Multiple  hits  were  allowed,  but  only  if  they  did  not  conflict  with  coverage 
maximization.  The  mandatory  multiple  hits  (MMH)  modification  to  TAP  allows  the  user  to 
designate  certain  DGZs  as  requiring  multiple  hits.  Put  simply,  sometimes  it  is  better  to  hit  3 
DGZs  twice  than  6  DGZs  once,  as  shown  in  Figure  5. 

Changes  to  the  code  to  implement  this  upgrade  followed  those  already  included  in  M202.  The 
internal  valuation  schemes  were  adjusted  so  that,  for  specified  DGZs,  multiple  hits  were  preferred 
over  single  hits.  Like  the  RT  enhancement,  TAP  was  able  to  take  advantage  of  work  performed 
on  M202  to  gain  this  new  capability  with  a  minimum  of  cost  and  risk. 


MODE  1  SCHEDULER. 

The  so-called  mode  1  scheduler  was  derived  from  the  Advanced  Missile  Model  (AMM).  It 
creates  a  launch  schedule  in  which  none  of  the  sorties  exceeds  a  maximum  allowed  fratricide 
level.  In  accomplishing  this,  no  constraint  is  placed  on  the  span  of  time  over  which  the  launches 
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Good  solution 


Figure  5.  Mandatory  multiple  hits  example. 


may  occur.  The  TAP  scheduler  takes  as  input  assigned  missiles  and  fratricide  data.  The  results 
reported  are  the  launch  time  for  each  missile  and  the  probability  of  fratricide  for  each  reentry 
body. 

Following  are  the  steps  followed  to  develop  the  schedule: 


•  determine  fratricide  interactions  between  RBs  from  all  the  sorties 

•  find  cycles  where  RBs  may  cause  fratricide  to  other  RBs  that  may,  in  turn,  ''ause  fratricide  to 
the  former 

•  order  the  sorties  so  those  of  higher  priority  are  early  in  the  list,  hence  eligible  for  preferred 
launch  times 

•  assign  a  launch  time  to  each  missile  such  that  it  does  not  violate  the  fratricide  constraint 

•  compute  final  probability  of  inter-sortie  fratricide  for  reporting 
Each  of  these  functions  is  described  in  more  detail  below. 


Exclusion  Periods  and  Cover  Pairs. 

An  exclusion  period  is  the  time  from  when  one  RB  could  possibly  begin  to  cause  fratricide  to 
another  RB,  to  the  time  when  no  further  fratricide  from  the  one  RB  to  the  other  is  possible.  While 
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there  are  exceptions,  a  general  rule  is  that  an  RB  arriving  at  its  DGZ  during  its  exclusion  period 
will  be  destroyed  before  it  can  complete  its  mission. 

The  computation  of  exclusion  periods  involves  using  “stayout  zones”  that  are  computed  by 
NWEM  and  made  available  to  TAP  in  a  data  file.  These  stayout  zones  contain  information  about 
the  size  and  location  of  regions  where  a  follower  RB  will  be  killed  by  fratricide,  and  when  those 
regions  exist  relative  to  the  builder  RB.  If  a  follower  RB’s  aimpoint  is  inside  one  of  these  regions, 
then  it  will  probably  be  killed  unless  it  is  scheduled  to  arrive  at  a  time  when  the  stayout  zone  does 
not  cover  the  DGZ.  Figure  6  shows  the  geometry  of  stayout  zones. 

To  speed  processing,  multiple  levels  of  filters  (Figure  7)  are  used  to  eliminate  RB  pairs  that  can 
easily  be  determined  to  have  no  fratricide  interaction.  These  filters  include  a  maximum  exclusion 
radius  where  RBs  separated  by  more  distance  than  any  stayout  zone  cannot  interact.  An  arbitrary 
box  around  the  builder’s  DGZ  further  eliminates  unwanted  DGZs  by  considering  the  maximum 
stayout  zone  size  for  the  RBs  of  interest.  A  maximum  exclusion  rectangle  test  then  orients  a 
rectangle  containing  all  stayout  zones  for  the  RB  pair  along  the  follower  RB’s  azimuth  and 
eliminates  more  DGZs  from  further  consideration.  DGZs  that  still  might  have  fratricide  are  then 
evaluated  in  detail  by  comparing  their  locations  with  each  of  the  dynamic  stayout  zones.  RBs  not 
eliminated  by  any  of  these  tests  arc  called  a  ‘‘cover  pair”  and  this  information  is  made  available  to 
subsequent  processes. 


Incoming  RB 


An  RB  must  fly  through  a 
nuclear  cloud  to  hit  DGZs  in 
stayout  zones 


Stayout  zones  vary  in  size 
and  location  with  time 

Each  of  the  example  zones 
exists  at  a  different  time 


Nuclear  detonation 

Figure  6.  Stayout  zone  geometry. 
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Figure  7.  Fratricide  filter  tests. 

Mutual  Cycles  and  Launch  Delays. 

The  problem  of  fratricide  mutual  cycles  is  solved  explicitly  to  minimize  overall  launch  delays. 
Mutual  cycles  are  chains  of  covered  sorties  that  loop  back  on  themselves  as  illustrated  in  Figure 
8.  A  small  cycle  in  this  example  is  G  covering  H  which,  in  turn,  covers  G.  These  cycles  are  a 
problem  for  the  scheduler  because  the  complex  fratricide  interactions  can  only  be  effectively 
resolved  if  the  cycle  is  considered  as  a  whole.  TAP  determines  appropriate  delays  between  the 

sorties  in  each  mutual  cycle  and  passes  the  deconflicted  cycle  on  for  assignment  of  launch  time. 

«. 
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Before  cycles  resolved 
© 


Alter  cycles  resolved 

© 


The  cydee  are  represented  as  a 
single  sortie  in  the  resultant  1st 


Figure  8.  Mutual  cycles  example. 


The  cycles  are  then  given  launch  times  as  if  they  were  individual  sorties.  Once  the  cycle  is  given 
a  launch  time,  it  is  decomposed  and  each  sortie’s  launch  time  is  established  using  the  delays 
determined  during  this  step. 


Sequence  the  Sorties  for  Scheduling. 

Once  cover  pairs  and  mutual  cycles  have  been  determined,  TAP  creates  a  list  of  the  sorties  to  be 
scheduled,  and  sorts  that  list  according  to  user-defined  target  priorities  and  the  complexity  of  the 
surrounding  fratricide  interactions:  more  important  sorties  go  first  in  the  list,  as  do  those  with  less 
complex  interactions.  This  ordered  list  of  sorties  is  then  ready  to  have  launch  times  computed. 

Assign  Launch  Times. 

In  assigning  launch  times  to  missiles,  TAP  takes  one  sortie  at  a  time  from  the  ordered  list 
prepared  in  the  previous  step.  It  determines  an  optimum  launch  time  for  the  sortie  that  best 
satisfies  the  objective  of  the  schedule:  either  minimum  span  of  launch  times,  or  minimum  span  of 
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impact  times.  If  this  launch  time  has  fratricide  problems,  the  program  searches  among  nearby 
times  until  one  is  found  that  doesn’t  violate  the  constraints. 

Compute  Probability  of  Fratricide. 

Once  all  the  sorties  have  been  assigned  launch  times,  the  final  probability  of  fratricide  is 
computed.  The  fratricide  function  is  illustrated  in  Figure  9.  The  computations  integrate  over  each 
exclusion  period  using  the  available  burst  times  and  exclusion  periods  for  the  RB  pair. 


Height  is  determined  by 
portion  of  possible 
azimuths  that  cause 
fratricide 

Slope  is  derived  from 
time-on-target  uncertainty 


Pf  equals  integrated  area 
of  curve  during  follower’s 
time-of-arrival  period 


Figure  9.  The  fratricide  function. 
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SECTION  3 

TAP.4  ENHANCEMENTS 


The  primary  enhancement  to  the  fourth  version  of  TAP  was  a  new  scheduler  mode  capable  of 
launching  sorties  at  a  predetermined  rate.  This  change  was  required  because  in  many  situations  it 
is  desirable  to  launch  a  boat’s  sorties  as  quickly  as  possible  rather  than  waiting  until  all  fratricide 
conflicts  have  cleared  up.  In  support  of  this  basic  requirement,  several  other  features  were 
included  in  this  “mode  2”  scheduler.  In  addition  to  the  new  scheduler  mode,  several 
enhancements  were  made  to  the  mode  1  scheduler,  mainly  to  give  it  the  ability  to  disregard 
certain  fratricide  relationships. 

MODE  2  SCHEDULER. 

The  mode  2  scheduler  attempts  to  minimize  fratricide  conflicts  while  launching  sorties  at  a 
user-determined  rate.  The  user  can  control  the  objectives  and  constraints  either  by  package  or 
sub-package.  (A  package  is  roughly  equivalent  to  a  boat,  and  a  sub-package  is  a  subset  of  that) 
The  same  fratricide  models  are  used  in  the  mode  2  scheduler  as  in  mode  1.  The  resulting  timing 
and  deconfliction  software  has  the  facility  for; 

•  scheduling  boats  with  split  launches  (several  groups  of  sequential  launches)  using 
sub-packages 

•  user  control  of  the  order  of  sub-packages 

•  user  control  of  the  delay  between  sub-packages 

•  user  control  of  the  order  of  packages  within  the  schedule 

•  specifying  explicitly  or  leaving  to  TAP  the  determination  of  each  aspect  of  the  resultant 
schedule  of  launches 

•  user-specified  or  program-determined  delays  between  packages 

•  user-defined  sub-packages  that  are  scheduled  as  a  group  within  each  package 

•  determination  of  times  when  a  sortie  could  be  safely  launched  if  it  was  not  launched  at  its 
appointed  time 

•  ability  to  disregard  certain  fratricide  conflicts 


12 


These  are  each  discussed  in  the  following  sections. 


Fixed  Launch  Rate. 

The  mode  2  scheduler  plans  launches  at  a  user-specified  rate.  For  example,  they  could  be  timed 
to  launch  once  every  60  seconds.  The  task  the  scheduler  performs,  then,  is  to  select  the  order  of 
launches  that  will  incur  the  least  fratricide. 

The  approach  used  to  solve  this  discrete  nonlinear  minimization  problem  comes  from  the 
discipline  of  statistical  mechanics.  The  algorithm.  Simulated  Annealing,  tests  many  possible 
orderings  and  drives  toward  a  global  minimum  by  always  accepting  better  results  and  sometimes 
accepting  worse  results.  This  allows  it  to  escape  local  minima  and  strive  toward  a  global 
optimum  solution.  (Because  of  the  nature  of  the  problem,  a  global  optimum  cannot  be  guaranteed 
without  examining  all  possible  orderings  of  sorties,  which  was  impractical  in  this  situation.) 

This  processing  applies  to  each  package  or  sub-package  but  not  across  all  sorties.  This  is  because, 
while  sorties  within  a  package  may  be  required  to  launch  at  a  fixed  rate,  packages  may  be 
launched  at  arbitrarily  different  times.  The  next  section  discusses  how  package  delays  are 
established. 

Inter-Package  Delay  Timing. 

If  TAP  is  directed  to  determine  inter-package  delays,  it  iterates,  trying  one  set  of  delays  and 
reordering  the  sorties  within  the  packages  to  minimize  fratricide.  It  then  tries  other  delays  until  an 
optimum  set  is  found.  This  iterative  approach  is  feasible  because  of  the  relatively  small  number 
of  packages  possible  in  the  United  Kingdom  scenario.  When  selecting  delays,  TAP  schedules 
package  times  that  prevent  sorties  in  one  package  from  causing  more  than  the  acceptable  amount 
of  fratricide  to  sorties  in  any  other  package.  Packages  may  be  delayed  as  long  as  necessary  to 
eliminate  this  inter-package  fratricide.  Other  aspects  of  inter-package  processing  are  similar  to 
those  of  sub-packages;  they  are  discussed  together  in  the  next  section. 

Sub-Packages. 

Sub-packages  must  be  scheduled  relative  to  each  other.  Tlie  user  can  specify  both  the  order  of 
sub-packages  within  a  package,  and  the  delay  for  each  sub-package.  If  one  or  both  of  these  is  not 
specified,  TAP  will  determine  it.  Figure  10  shows  an  example  of  how  packages  and  sub-packages 
are  arranged.  If  TAP  is  tasked  with  determining  the  order  and  times  of  sub-packages,  it 
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Figure  10.  Package  and  sub-package  timelines. 


formulates  the  solution  according  to  the  classical  traveling  salesman  problem;  pick  the  order  of 
sub-packages  that  minimizes  the  total  launch  span  of  the  sub-packages.  Figure  11  shows  the 
major  functions  of  the  mode  2  scheduler  and  how  they  interact.  Note  that  each  of  these  functions 
(package  delays,  sub-package  delays,  order  of  sorties,  order  of  packages/sub-packages)  builds  on 
lower-level  functions  in  a  highly  iterative  fashion.  For  example,  if  sub-package  times  and  order 
are  not  specified,  TAP  selects  an  order  and  posits  delay  times,  then  performs  the  sortie  ordering 
function  to  minimize  fratricide  within  the  fixed  launch  rate  constraint.  This  solution  is  evaluated 
and  compared  with  other  iterations  of  different  sub-package  orders  and  different  delays. 


Preordered  Sorties. 

The  user  can  establish  the  order  of  launch  of  any  or  all  sorties  input  to  the  scheduler.  This 
provides  explicit  control  for  areas  of  high  priority  and  for  situations  in  which  other  issues  besides 
those  considered  by  TAP  affect  the  desired  times  on  target. 


Relaunch  Windows. 

Once  a  complete  schedule  has  been  derived,  TAP  can  search  for  opportunities  to  launch  each 
missile  later  than  its  scheduled  launch  time.  Tliese  relaunch  windows  would  be  useful  when  a 
sortie  was  not  launched  at  its  appointed  time  but  needed  to  be  sent  on  its  way  at  the  next  time  at 
which  that  it  wouldn’t  conflict  with  other  missions.  TAP  computes  all  windows  of  opportunity  up 
to  the  “all  clear”  time,  after  which  there  are  no  further  fratricide  considerations.  Figure  12  shows 
an  example  of  relaunch  windows. 
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The  scheduler  can  be  entered 
with  any  set  of  initial  conditiorts 


Functions  lower  on  this  chart 
invoke  higher  functions  to 
accomplish  their  obiectives 


Figure  11.  Package  and  sub-package  functions. 
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Al  dear  time - 


Relaunch  windows 

Figure  12.  Relaunch  windows. 
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Disregard  Certain  Cover  Relationships. 

To  provide  more  control  for  the  planners,  the  capability  to  disregard  certain  fratricide  interactions 
was  incoiporated  into  TAP.  Three  situations  can  be  controlled: 

•  ignore  fratricide  between  user-specified  RBs  and  all  other  RBs 

•  ignore  fratricide  between  all  RBs  aimed  at  the  same  DGZ 

•  ignore  fratricide  between  all  RBs  from  two  or  more  nominated  sorties 

If  any  of  these  are  requested  by  the  user,  TAP  will  consider  that  there  is  no  fratricide  in  those 
.situations. 

MODE  1  SCHEDULER. 

Several  minor  enhancements  were  made  to  the  mode  1  scheduler.  These  included  eliminating 
overlapping  launch  times  and  ignoring  certain  fratricide  interactions. 

Eliminating  Overlapping  Launch  Times. 

In  mode  1,  the  planners  could  preschedule  the  launches  of  specific  missiles  before  submitting  the 
balance  to  TAP  for  processing.  A  change  was  made  for  TAP.4  so  that  any  TAP-selected  launch 
times  lie  outside  the  timespan  of  the  prescheduled  launches  for  each  boat  All  program-derived 
times  will  be  either  before  the  first  or  after  the  last  prescheduled  launch. 

Disregarding  Certain  Cover  Relationships. 

To  provide  more  control  for  the  planners,  the  capability  to  disregard  certain  cover  relationships 
was  incorporated  into  TAP  in  the  same  fashion  as  for  mode  2,  above.  Three  situations  can  be 
controlled: 

•  ignore  fratricide  between  user-specified  RBs  and  all  other  RBs 

•  ignore  fratricide  between  all  RBs  aimed  at  the  same  DGZ 

•  ignore  fratricide  between  all  RBs  from  two  or  more  nominated  sorties 

If  any  of  these  are  requested  by  the  user,  TAP  will  consider  that  there  is  no  fratricide  in  those 
situations. 
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SECTION  4 
MAINTENANCE 


While  the  enhancements  discussed  above  compose  most  of  the  TAP  effort  under  this  contract, 
some  maintenance  changes  were  made  to  the  program  to  improve  its  effectiveness.  The  primary 
ones  are  listed  below.  Additionally,  several  program  anomalies  were  found  and  repaired. 

The  mode  1  scheduler  was  updated  to  consider  whole  boats  instead  of  forces  when  minimizing 
the  launch  span.  If  a  boat  had  missiles  with  different  numbers  of  RBs,  then  those  missiles  would 
be  in  different  forces  as  reckoned  by  TAP.  This  change  explicitly  precludes  missiles  on  the  same 
boat  from  being  assigned  the  same  launch  times. 

A  major  factor  determining  the  fratricide  stayout  zone  sizes  and  locations  is  reentry  velocity. 
However,  NWEM  data  was  selected  based  only  on  height  of  burst  and  reentry  angle.  The  change 
to  TAP  was  to  select  fratricide  data  using  reentry  velocity  in  addition  to  the  other  factors,  thus 
improving  the  fidelity  of  the  fratricide  modeling. 

In  TAP’s  assignment  processing,  sorties  could  be  input  that  were  already  assigned.  These 
preassigned  sorties,  however,  needed  to  have  all  their  RVs  assigned  to  DGZs.  A  change  was 
made  to  the  program  to  allow  the  planners  to  specify  only  a  subset  of  the  RV-to-DGZ  tieups,  with 
TAP  completing  the  set  of  assignments.  These  partially  preassigned  sorties  would  then 
incorporate  the  planner’s  explicit  targeting  needs,  while  TAP’s  completion  of  them  would  ensure 
that  general  objectives  were  also  met. 

There  are  several  curve-fitting  functions  embedded  in  TAP.  These  include  a  rough  estimate  of 
achievability,  domain  scaling  factors,  and  relocatable  target  set  potential  circles.  The  coefficients 
included  in  the  first  versions  of  TAP  were  derived  for  Trident  1  missiles.  Using  the  JSTPS 
achievability  program  for  Trident  II,  Logicon  le-fit  the  curves.  These  new  functionalizations  aid 
the  program  by  providing  better  predictors  of  achievability. 

The  ability  to  preassign  sorties  in  TAP  assumed  default  values  for  a  variety  of  trajectory 
parameters.  However,  once  missions  had  been  flown  through  TRITEST  (the  Trident  mission 
validating  program),  better  trajectory  information  was  available  that  would  eliminate  intra-sortie 
fratricide,  among  other  things.  A  change  was  made  to  TAP  to  allow  input  of  in-flight  spacing  and 
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tiine-of-flight  controls  to  maintain  concurrency  with  TRITEST.  These  new  inputs  ensure  accurate 
time-of-flight  information  for  use  during  scheduling. 


SECTION  5 

SUPPORT  AND  ADVICE 


In  addition  to  continuing  the  development  of  the  TAP  software,  Logicon  performed  other  support 
tasks  under  this  contract  These  activities  included  training,  documentation,  and  technical 
consultation. 

TRAINING. 

As  an  integral  part  of  each  major  software  delivery  of  TAP,  a  training  course  was  presented.  This 
training  was  directed  primarily  at  users  of  the  program.  The  multi-day  courses  explained  the 
many  inputs  and  controls  in  TAP  and  how  the  program  is  executed.  Further,  an  explanation  of  the 
software  was  provided,  since  an  understanding  of  this  helps  users  interpret  program  results.  The 
training  went  into  some  depth  in  explaining  the  program’s  structure  and  data  manipulation.  The 
intent  was  to  assist  both  the  using  community  and  those  who  will  be  maintaining  and  supporting 
the  program  in  the  future. 

NWEM  SUPPORT. 

The  Nuclear  Weapons  Environment  Model  (NWEM)  is  a  program  developed  under  DNA 
auspices  primarily  for  use  with  AMM.  In  support  of  TAP,  Logicon  rehosted  the  program  from 
the  IBM  mainframe  environment  to  the  VAX.  To  aid  the  use  of  the  program,  an  interactive  user 
interface  was  developed  using  a  question-and-answer  style  of  data  entry.  This  replaced  NWEM’s 
“card  column”  style  of  input.  A  manual  was  prepared  that  described  the  use  of  NWEM  on  the 
VAX  with  the  new  interface.  To  help  DGSWS  understand  the  functioning  of  NWEM,  Logicon 
held  technical  discussions  between  weapons  effects  experts  (including  an  NWEM  developer)  and 
DGSWS  personnel.  This  interchange  aided  understanding  of  what  nuclear  effects  NWEM  models 
and  how  it  models  them. 

TECHNICAL  INTERCHANGE. 

During  the  course  of  this  effort,  Logicon  led  sessions  in  detailed  reviews  of  design  and 
implementation  of  the  many  enhancements  to  TAP.  These  sessions  helped  the  developers 
understand  the  program’s  objectives  and  helped  ensure  that  DGSWS  was  provided  software  that 
met  their  needs.  Each  software  delivery  was  accompanied  by  a  team  of  developers  who  worked 
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with  DGSWS  to  install  the  program  and  test  it  at  the  site.  These  extended  periods  also  aided  the 
staff  at  DGSWS  by  giving  them  an  opportunity  to  discuss  and  review  TAP  issues  with  developers 
in  an  informal  environment 

Reports  were  also  provided  regarding  other  issues  in  which  Logicon  is  involved.  Ongoing 
research  in  algorithmic  areas  was  reviewed,  including  discussions  of  the  use  of  neural  networks 
in  mission  planning,  and  the  application  of  the  Lin-Kernighan  optimization  methodology. 
Reports  were  made  of  concurrent  updates  being  performed  on  M202  for  JSTPS.  Several  of  these 
M202  developments  were  subsequently  incorporated  into  TAP.  Further,  Logicon  responded  to 
various  requests  for  analysis  of  potential  program  modifications,  including  evaluation  of  program 
impact  and  estimates  of  effort  required. 
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SECTION  6 
CONCLUSION 


Two  new  versions  of  TAP  were  delivered  to  DGSWS  under  this  contract.  The  TAP  program  with 
these  updates  is  a  very  flexible  and  highly  reliable  system  that  leverages  its  M202  ancestry  to 
provide  a  powerful  set  of  software  that  is  mature.  Many  new  features  were  added,  including  a 
timing  and  deconfliction  capability  that  allows  for  two  different  scheduling  assumptions. 

The  work  was  completed  according  to  schedule,  within  budget  constraints,  and  to  the  satisfaction 
of  the  Ministry  of  Defence. 
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APPENDIX 

GLOSSARY  OF  TERMS 


The  following  are  selected  word  definitions  for  terminology  commonly  used. 


Achievability 


AMM 


Builder  RB 

Cover 


DGZ 

DGSWS 


Domain 


Follower  RB 


The  ability  of  a  missile  to  strike  given  aimpoints.  It  is  affected  by 
weapon  system,  range  to  targets,  launch  latitude,  launch  azimuth, 
among  other  factors. 

Advanced  Missile  Model.  AMM  is  a  program  used  by  the  Air 
Force  to  model  a  variety  of  strategic  situations.  TAP’s  mode  1 
scheduler  was  derived  from  AMM. 

The  RB  that  potentially  causes  fratricide.  See  also  Follower  RB. 

A  fratricide  relationship  between  two  RBs.  An  RB  is  said  to  cover 
another  RB  if  it  can  cause  fratricide  to  that  RB. 

Also,  a  missile  assignment.  A  missile  covers  a  DGZ  if  it  is  assigned 
to  the  DGZ. 

Desired  Ground  Zero.  An  aimpoint. 

Director  General  Strategic  Weapons  Systems.  The  British  Ministry 
of  Defence  organization  that  directed  the  development  of  TAP. 

An  elliptical  region  that  quantizes  the  capability  of  a  weapon  to 
cover  targets.  It  is  used  during  missile  assignment  to  direct  the  flow 
of  processing. 

The  RB  that  potentially  receives  fratricide  damage.  See  also 
Builder  RB. 
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Fratricide 

JSTPS 

M202 

MMH 

MOB 

NSWC 

NWEM 

Package 

RB 

RT 


Damage  from  one  friendly  weapon  to  another.  Fratricide  damage  is 
caused  by  blast,  dust  and  debris,  radiation,  and  other  effects.  It 
prevents  the  follower  RB  from  detonating  according  to  plan. 

Joint  Strategic  Target  Planning  Staff.  The  U.S.  military 
organization  charged  with  developing  the  Single  Integrated 
Operating  Plan  (SIOP)  for  a  strategic  nuclear  war. 

Missile  Application  Program.  The  operational  program  used  at 
JSTPS  for  assigning  strategic  ballistic  missiles  to  aimpoints. 

Mandatory  multiple  hits.  A  TAP  assignment  control  that  directs  the 
program  to  prefer  hitting  DGZs  several  times  rather  than  hitting  a 
larger  number  of  DGZs  singly. 

Main  operating  base  of  a  group  of  relocatable  targets. 

Naval  Surface  Warfare  Center,  the  U.S.  organization  that 
developed  the  Trident  II  achievability  model  used  in  TAP. 

Nuclear  Weapon  Environment  Model.  This  DNA  program  that 
determines  fratricide  damage.  The  results  are  used  by  TAP. 

A  set  of  sorties  scheduled  as  a  group.  Typically,  a  package  is 
equivalent  to  the  set  of  missiles  in  a  single  submarine. 

Reentry  body.  The  nuclear  warhead  from  a  ballistic  missile. 
Sometimes  referred  to  as  a  reentry  vehicle  (RV). 

Relocatable  target.  An  RT  is  a  DGZ  that  moves,  making  it  more 
difficult  to  target.  An  example  is  a  train-based  missile  launcher. 
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Scheduling 


Set  potential  circle 


Sortie 


Stayout  zone 


STRAP 


Sub-package 


TRAP.2 


TRITEST 


The  process  of  assigning  launch  times  to  individual  missile  sorties. 
The  scheduling  process  is  driven  by  planner-directed  time 
constraints,  and  fratricide  minimization. 

A  region  wherein  RTs  may  move  and  be  kept  at  risk  with  a  given 
probability.  A  smaller  probability  yields  a  larger  circle. 

A  missile  and  its  mission.  Sometimes  used  to  refer  solely  to  the 
missile. 

A  fratricide  region  wherein  a  builder  RB  will  destroy  a  follower 
RB  if  the  follower  arrives  within  a  given  timespan.  Typically  there 
will  be  several  stayout  zones  for  each  RB  pair,  one  for  each  of  a  set 
of  times. 

Simplified  Trident  Rapid  Achievability  Predictor.  This  is  a 
program  that  models  the  trajectory  of  Trident  sorties  and 
determines  whether  a  particular  missile  can  hit  a  given  set  of 
DGZs. 

A  subset  of  sorties  within  a  package  that  are  scheduled  as  a  group. 
Sorties  within  a  sub-package  are  launched  in  succession  with  no 
pauses  between  each  launch.  Sub-packages  may  have  pauses 
between  them. 

Trident  Rapid  Accessibility  Program.  An  achievability  program 
used  by  JSTPS  to  model  Trident  II  trajectories. 

Trident  Tester.  TRITEST  uses  STRAP  and  other  data  to  determine 
optimum  trajectory  parameters  to  achieve  the  mission  goals  of  each 
sortie. 
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